Policy Manager is an application in the 2019.2 release of the Itential Automation Platform (IAP) designed to focus on policy management and help target policies to rule groups in your organization. It provides direct configurability along with other features such as:
- Ability to import policies.
- Push changes to devices.
- Rule optimization via Template Builder.
Policy Manager uses device specific TextFSM templates to convert native config into JSON, and Jinja2 templates to convert JSON into device config. This guide provides detail on all the features available in Policy Manager and takes you through many of the tasks used to manage policies on devices.
Policy Page
Policies Card Collection
The Policies page allows new policies to be created, existing policies to be deleted, and rule updates through the policy edit page. All policies created in IAP 2019.2 are displayed in a card format. You can paginate, filter, and sort policies by field. Data fields can also be toggled for display.
Deleting Policies
A policy can link to multiple targets on the same device or it can link to multiple targets across multiple devices. Deleting a policy requires all the targets to be unlinked from the policy. Deleting a single policy will display a table of targets to which the current policy is linked and deleting multiple policies will display the targets to which all the policies are linked.
Note: You cannot delete policies that have linked targets.
Modifying Policies
On the policy edit page, there are five tabs: Rules, Targets, Redundant Rules, Raw, Raw Expanded. The rules table allows you to create, delete and reorder (by manual input index or drag and drop) rules. The rules order (index) is converted to sequence numbers in the background prior to pushing to the device.
Creating and Updating Rules (in a Single Policy)
Every rule is unique and rules do not have their own database collection. If you want to give the same rule to two different policies, you must create two rules - one in each policy. The Name and Action fields are required to create a new rule. In the 2019.2 release, multiple networks and multiple services are not supported. Only the first source network, destination network,and service will be applied on push.
Available Networks use server side filtering and requires a network name. Address search is not supported in the 2019.2 release.
Selected Networks are filtered on the client side, and the networks list will auto-filter as you type.
Updating Targets
On the Targets tab of the policy page, a list of linked targets are displayed in a table. You can unlink a target by removing the device chip from the table. You can also unlink a target from a policy from the Devices page.
When adding a target to a policy, a list of all targets is provided. Select and save the targets to link them to the current policy. A target cannot have more than one policy applied. From the Add Targets view, the application will restrict you from adding targets that already have policies.
Redundant Rules
The Redundant Rules tab becomes available when the current policy has redundant rules. This page has all the same capabilities as the Rules tab but with the redundant rules highlighted. The example screenshot shows that rules 1, 2, and 5 are redundant to rule 3 and 4 (which has any-to-any networks).
Raw (JSON)
A policy Mongo document has references to documents in other collections. The example page below shows the de-referenced JSON object of a policy.
Raw Expanded (JSON)
Depending on the device type, a rule in a policy can have multiple networks/services, or just one of each. For device types that cannot group networks/services, the page will show the expanded version of the rules.
For example, a rule with three destination networks (1,2,3) and two source networks (A,B) and one Service (TCP) expands into six rules: 1-A-TCP, 1-B-TCP, 2-A-TCP, 2-B-TCP, 3-A-TCP, 3-B-TCP.
Rule Templates Page
The Rule Templates page is the same as the Policies page except that rule templates do not link directly to targets. A policy can have rules or rule templates.
Devices Page
Devices Card Collection
The Devices page allows new devices to be imported, existing devices to be forgotten (removed from our database), and targets to be updated through the device edit page.
Forget Device
A device can be forgotten at any time without any restrictions. It removes the device document from the database, and the linked policies will lose reference to the device targets in the policy documents.
Importing Device: Frontend
The Import Device modal searches through all the devices a system is connected to. In the 2019.2 release, only one device can be imported at a time. Additionally, only IOS and IOSXR devices have templates ready for import. The example screenshot below shows an IOSXR device connected by NSO, which has a different device type than a device connected by Ansible.
Importing Device: Backend
On device import, via parsing methods in Template Builder, configurations for the policies (access-lists) and targets (interfaces) are parsed through the import-policy template and import-target template. Documents are then created for policies, networks, services, and device that correctly reference each other. This aligns with the Itential data model.
Push / Dry Run
The Push device modal allows you to view and accept a dry run before making changes to the device. A dry run is required on every push, and the push method takes in the dry run as an input. The dry run is displayed in config diff (the JSON view shows the entire array of policies).
Note: Pushing without a dry run will follow the same logic to retrieve the dry run - it will take just as much time.
The example screenshot below shows that a new policy named test is linked to a Gigabit Ethernet 1 inbound policy, and a new policy appears in the policy changes. For push-test-1, it has a rule with a new network assigned, and it shows a deletion and addition. Reordering of the rules also shows as a deletion and addition.
Networks Page
Networks Card Collection
The Network page allows new networks to be created, existing networks to be deleted, and network updates through the edit page.
Deleting Networks
A network is either a source or destination of a rule (which is either part of a policy or a rule template). When deleting one or many services, a modal is displayed with all the policies and rule templates the deletion affects. You cannot delete networks that have linked rules (policies/rule templates).
Creating and Updating Networks
When creating a new network, or updating an existing network, the network is validated via Policy Engine.
Services Page
Services Card Collection
The Service page allows new services to be created, existing services to be deleted, and service updates through the edit page.
Deleting Services
A service is only referenced in a rule (which is either part of a policy or a rule template). When deleting one or many services, a modal is displayed with all the policies and rule templates the deletion affects. You cannot delete services that have linked rules (policies/rule templates).
Creating and Updating Services
In the 2019.2 release, you can add the protocol type (TCP,ICMP, etc.) to a rule.
Admin Page
The Admin page is used to correctly assign templates to specific device types for import and export. You can create a new admin document by entering a new device type name. The Import Template (policies and targets) field dropdown provides a list of TextFSM templates to select from, while the Export Template will list the Jinja2 templates. The Expand Rule field is a boolean for whether to allow grouped networks and group services. With this release, the rules for supported device types can be expanded to have only one network and service.
